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Mapping Between the Multimedia Messaging Service (MMS) 
and Internet Mail 


Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 


Abstract 


The cellular telephone industry has defined a service known as the 
Multimedia Messaging Service (MMS). This service uses formats and 
protocols that are similar to, but differ in key ways from, those 
used in Internet mail. 


One important difference between MMS and Internet Mail is that MMS 
uses headers that start with "X-Mms-" to carry a variety of user 
agent- and server-related information elements. 


This document specifies how to exchange messages between these two 
services, including mapping information elements as used in MMS 
X-Mms-* headers as well as delivery and disposition reports, to and 
from that used in SMTP and Internet message headers. 
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1. Introduction 


1.1. Scope 


This document describes how to exchange messages between Multimedia 
Messaging Service (MMS) systems (as defined by [3GPP] [3GPP2] [OMA] ) 
and Internet mail systems (that is, [SMTP] and [Msg-Fmt]). This 
includes the translation of message formats, message header elements, 
message delivery reports [DSN-Msg], and message disposition reports 
[MDN]. 


The MMS architecture [Stage_2] and specifications [Stage_3] refer to 
interfaces as reference points named MMx. For example, MM1 is the 

client-server interface, MM4 is the server-server interface, and MM3 
is an interface to "external" or non-MMS systems. The specification 
in this document can be used for message exchange between any system 
that uses Internet message formats and protocols and an MMS system; 

from the perspective of the MMS system, reference point MM3 is used. 


This document includes support for voice messages specified by the 
Voice Profile for Internet Mail [VPIM]. The VPIM specification 
allows voice messages to be exchanged between voice mail systems 
using the Internet mail format [Msg-Fmt] and transported via [SMTP]. 
Thus, the MMS MM3 interface supports the ability to exchange voice 
messages between an MMS system and a voice mail system. Note that 
such use is distinct from voice media being part of a user-composed 
multimedia message. 
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Note that MM3 can also be used for interworking with "external" 
(non-MMS) systems other than Internet mail, such as Short Messaging 
Service (SMS) and access to external mail stores (such as a voice 
mail system). This specification does not address these other uses 
or sub-interfaces of MM3; it is only concerned with Internet mail 
interworking and specifically exchange of messages. 


All MM3 Stage 2 [Stage_2] functions are supported except for reply 
charging and sender address hiding. 


1.2. Conventions Used in This Document 


The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 
and "MAY" in this document are to be interpreted as described in "Key 
Words for Use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 


1.3. Definitions 


Body |The portion of an [SMTP] message’s Content 
| following the Header (that is, following the 

first blank line). The Body may contain 

structured parts and sub-parts, each of which 
|may have its own Header and Body. The Body 
|contains information intended for the message 
eee: (human or software). 

The portion of an SMTP message that is 

delivered. The Content consists of a Header 
ie a Body. 

Disposition Report | Feedback information to an originator User 
|Agent by a recipient User Agent about 

handling of an original message. This may 

include notification that the message was or 

|was not read, was deleted unread, etc. 


Message Disposition 
Notification 


Envelope |The portion of an SMTP message not included in 
[the Content, that is, not in the Header or in 
Ke Body. While some of it may be copied into 
the Content on delivery, envelope information 
[exists only while the message is in transit, 
|and contains information used by SMTP agents 
| (Mail Transfer Agents (MTAs)). 


See [SMTP], Section 2.3.8. 
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Header |The first part of an SMTP message’s Content. 
bee Header is separated from the Body by a 
blank line. The Header consists of Fields 
| (such as "To:"), also known as Header Fields 
|or Headers. The message Header contains 
| information used by User Agents. 


Relay/Server An MMS server. See [Stage_2]. For purposes 
of this document, an MMS Relay/Server acts as 
la gateway when it receives or sends messages 
|via Internet mail. 

User Agent |an MMS or email user agent. 


4. Abbreviations 


MSA |Message Submission Agent. A server that accepts messages 
| from User Agents and processes them, either delivering 
them locally or relaying to an MTA. See [Submission]. 


MTA |Mail Transfer Agent. A server that implements [SMTP]. 


.5. Assumptions 


It is assumed that the reader is already familiar with the contents 
of the 3GPP2 MMS Specification Overview [Overview], MMS Stage 1 


(requirements) [Stage_1] and Stage 2 (architecture and abstract 
messages) [Stage_2], and 3GPP/3GPP2 Stage 3 (protocols) [Stage_3] 
documents. It is also assumed that the reader is familiar with 


Internet mail, especially RFC 2821 [SMTP] and RFC 2822 [Msg-Fmt]. 
Mapping Between MMS and Internet Mail 


This section defines the interworking between MMS Relay/Servers and 
External Servers using native [SMTP]. That is, information elements 
are exchanged using standard Internet message [Msg-Fmt] header 
fields, such as those in [Hdrs], and standard [SMTP] elements. 


SMTP and Internet mail extensions are used for features such as 
delivery reports, message expiration, and discovery of server support 
for optional features. 
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2.1. Mapping Specification 
2.1.1. MMS to Internet Mail 


When sending a message to an Internet mail system, the MMS 
Relay/Server MUST convert the MM if required, and MUST comply with 
the requirements of [SMTP]. 


The MMS Relay/Server SHOULD use the information elements associated 
with the MM to define the control information (Internet message 
header fields and SMTP envelope values) needed for the transfer 
protocol. 


Section 2.1.3 lists the mappings between X-Mms-* headers and Internet 
message header fields and SMTP values. 


Delivery and read report MMs SHOULD be converted to standard Internet 
message report format (multipart/report). In addition to converting 
Internet Message reports, the MMS Relay/Server MUST generate delivery 
and read report MMs for received messages as appropriate. See 
Section 2.1.4 for more information. 


2od o2 Internet Mail to MMS 


When receiving a message from an Internet mail system, the MMS 
Relay/Server converts incoming messages to the MM format used within 
the receiving system. 


The MMS Relay/Server converts control information received from the 
Internet mail server into appropriate information elements of an MM. 


Section 2.1.3 lists the mappings between X-Mms-* headers and Internet 
message header fields and SMTP values. 


Standard Internet message report format (multipart/report) messages 
MAY be converted to delivery or read report MMs, as appropriate. In 
addition to converting report MMs, implementations conforming to this 
document MUST generate standard Internet message delivery and 
disposition reports for received Internet messages as appropriate. 
See Section 2.1.4 for more information. 
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3. MMS Information Element Mappings 


The mappings between MMS elements and SMTP/Internet message elements 
( [SMTP] parameters, [Msg-Fmt] headers, and [DSN-Msg] fields) are 
summarized in table 1 below, and detailed in subsequent sections. 
The "MMS Headers" are from [OMA-MMS]. Note that only information 
elements that need to be mapped are listed. [Msg-Fmt] headers not 
listed here SHOULD be passed unaltered. 


2.1.3.1. Table 1: Information Element Mappings 


Information Elem | [SMTP] Element [Msg-Fmt ] Header | MMS Header 


| | 
| | 
3GPP MMS Version |N/A |N/A | X-Mms-3GPP-MMS 
| | | -Version: 
Message Type |N/A |N/A |X-Mms—Message- 
(of PDU) | | | Type: 
| | 
Transaction ID |N/A |N/A |X-Mms-Transact 
| | | ion-Id: 
Message ID |N/A |Message-ID: |Message-ID: 
| | | 
Recipient |RCPT TO |To:, Ce:, or |To:, Ces, Bees 
address(es) | address (es) |omitted (Bcc) 
Sender’s address |MAIL FROM From: From 


|address if 
|user-originated; 
|MUST set MAIL 
|FROM to null 
("<>") for all 
automatically- 

| generated MMs 


Content-Type: Content-type: 


For voice mes- 
sages compliant 
|to [VPIM], see 
|Note 2 


| 
Content type |N/A 

| 

| 

| 

| 
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Information Elem 


[SMTP] Element 


| [Msg-Fmt] Header|MMS Header 


Sender visib- 


not currently 


not currently X-Mms-Sender- 


na 


| 
| 
Message class enna eve set ’Prece X-Mms-—Message- 
|MUST set MAIL | dence: bulk’ | Class: 
| FROM to null [on class=auto | 
| ("<>"). | | 
| | | 
Date and time N/A Date Date: 
of submission 
| | | 
Time of expiry | DELIVER-BY |N/A |X-Mms-Expiry: 
| [Deliver-By] | | 
| | | 
Earliest deliv- | (only for submis-|N/A |X-Mms-Delivery 
ery time sion; not relay | | -Time: 
Delivery report | DSN [DSN-SMTP ] |N/A |X-Mms-Delivery 
request | SHOULD also | —-Report: 
|specify recip- | 
|ient address as | 
ORCPT; SHOULD 
also specify 
| ENVID | 
| | 
Importance (a/k/a|N/A | 
"priority") | Priority: 
| 
| 
| 
| 


ility upported) Visibility: 
Read reply N/A Disposition- X-Mms-Read- 
request Notification Reply: 

-To: [MDN] 


Reply-charging 
permission 


( 
supported) 
( 


not currently 
supported) 


not currently 
upported) 


X-Mms-Reply- 
Charging: 


Ua 


Reply-charging 
permission 
deadline 


(not currently 
supported) 


not currently X-Mms-Reply- 
Charging- 


Deadline: 


Ua 


Reply-charging 
permission 
limitation 


| 
| 
| 
| (not currently 
supported) 


(not currently 
supported) 


X-Mms-Reply- 
Charging- 
Size: 


| 
| 
| 
upported) | 
| 
| 
| 


Gellens 
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Information Elem | [SMTP] Element | [Msg-Fmt] Header|MMS Header 


Reply charging 
usage request 


not currently 


( not currently X-Mms-Reply- 
supported) 


( 
supported) Charging- 
Id: 


Reply charging (not currently (not currently X-Mms-Reply- 


| 
| 
| 
| 
usage reference supported) supported) | Charging: 
Subject |N/A |Subject: | Subject 
| | | 
Previously-sent |N/A |Resent-From: |X-Mms-Previous 
by | | | ly-Sent-By: 
| | | 
Previously-sent N/A Resent-—Date: X-Mms-— 
date Previously- 
| | | Sent-Date- 
| | | and-Time: 
| | | 
Hop/host trace |N/A |Received: | (Not sup- 
| | ported) 
Sensitivity |N/A |Sensitivity: see|N/A 
| | Note 1 
| | | 
Content |N/A |<message body> |<message body> 
| 


Note 1: The [VPIM] ’Sensitivity’ header element indicates the 

privacy requested by the message originator (values are "personal" or 

"private"); per [VPIM], a message recipient MUST NOT forward a 

message with a ’Sensitivity’ header. Since sensitivity is not an MMS 

feature, any messages that contain a ’Sensitivity:’ header SHOULD NOT 

be sent to an MMS system. 

Note 2: [VPIM] specifies how conforming messages are identified. 
2.1.3.2. Conversion of Messages from MMS to Internet Format 

3GPP MMS Version 

The ’X-Mms-—3GPP-MMS-Version:’ header, if present, SHOULD be removed. 

Message Type (of PDU) 


The ’X-Mms-Message-Type:’ header, if present, SHOULD be removed. 
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Transaction ID 
The ’X-Mms-Transaction-Id:’ header, if present, SHOULD be removed. 
Message ID 


The ’Message-Id:’ header MUST be retained. If not present, it MUST 
be created, with a unique value, per [Msg-Fmt]. 


To facilitate the case where an MMS message traverses the Internet 
prior to returning to an MMS system, implementations might wish to 
retain the ’X-Mms-Message-Id:’ header. Such systems should be aware 
that headers that begin with "X-" might be removed during transit 
through Internet MTAs. 


Recipient(s) address 


The address of each recipient MUST be transmitted in the [SMTP] 
envelope as a RCPT TO value. All disclosed recipients SHOULD also 
appear ina ’To:’ or ’Cc:’ header. At least one ’To:’, '’Cc:’, or 
"Bec:’ header MUST be present. If none are present, a ’To:’ header 
SHOULD be created using empty group syntax whose name gives an 
indication to a human reader, for example, ’To: undisclosed- 
recipients:;’. 


The ’To:’ header SHOULD NOT appear more than once. The ’Cc:’ header 
SHOULD NOT appear more than once. 


Each recipient address MUST obey the length restrictions per [SMTP]. 


Current Internet Message format requires that only 7-bit US-ASCII 
characters be present in headers. Non-7-bit characters in an address 
domain must be encoded with [IDN]. If there are any non-7-bit 
characters in the local part of an address, the message MUST be 
rejected. Non-7-bit characters elsewhere in a header MUST be encoded 
according to [Hdr-Enc]. 


All recipient addresses in the [SMTP] envelope must be fully- 
qualified in accordance with [SMTP]. In particular, messages MUST 
NOT be sent to an Internet mail system with an unqualified E.164 
number (i.e., a number with no domain) instead of a fully-qualified 
domain name. 


All addresses in ’To:’, ’Cc:’, and ’Bcc:’ headers MUST be in the form 


of fully-qualified domains. Unqualified E.164 numbers MUST NOT be 
used. 
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Sender address 


The address of the message sender SHOULD appear in the ’From:’ 
header. 


The address of the message sender for all user-generated messages 
(’X-Mms-Message-Class: Personal’) SHOULD be transmitted in the 
[SMTP] envelope as the MAIL FROM value. 


The return addresses in the [SMTP] envelope must be fully-qualified 
in accordance with [SMTP]. In particular, messages MUST NOT be sent 
to an Internet mail system with an E.164 number instead of a fully- 
qualified domain name. Note that qualified E.164 numbers, that is, 
those that contain an E.164 number as the local-part of an address 
that also includes a domain, are acceptable. 


The address(es) in the ’From:’ header SHOULD be in the form of 
fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be 
used. 


Because of the risk of mail loops, it is critical that the MAIL FROM 


be set to null ("<>") for all automatically-generated MMs (such as 
’X-Mms-Message-Class: Auto’). The MAIL FROM value MUST be set to 
null for all automatically-generated messages. This includes 


reports, "“out-of-office" replies, etc. 


Current Internet message format requires that only 7-bit US-ASCII 
characters be present in headers. Non-7-bit characters in an address 
domain must be encoded with [IDN]. If there are any Non-7-bit 
characters in the local part of an address, the message MUST be 
rejected. Non-7-bit characters elsewhere in a header MUST be encoded 
according to [Hdr-Enc]. Note that it would be possible to define an 
[SMTP] extension to permit transmission of unencoded 8-bit 
characters, but in the absence of such an extension [Hdr-Enc] MUST be 
used. 


The sender address MUST obey the length restrictions of [SMTP]. 
Content type 


The ’Content-Type:’ header SHOULD be preserved. 
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Message class 


The ’X-Mms-Message-Class:’ header MAY be retained in order to provide 
information on the source of the message. A ’Precedence: bulk’ 
header MAY be inserted for class=auto or class=advertisement. See 

’ Sender Address’ above. (Class=personal and class=informational do 
not require special handling.) 


Time of Expiry 

The ’X-Mms-Expiry:’ header, if present, SHOULD be removed. 

The remaining time until the message is considered expired SHOULD be 
transmitted in the [SMTP] envelope by using the DELIVER-BY extension 
with a by-mode of "R", as specified in [Deliver-By]. 

Note that the [SMTP] DELIVER-BY extension carries time remaining 
until expiration; each server decrements the value by the amount of 
time it has possessed the message. The ’X-Mms-Expiry:’ header may 
contain either the absolute time at which the message is considered 
expired or the relative time until the message is considered expired. 
Earliest delivery time 


The ’X-Mms-—Delivery-Time:’ header, if present, SHOULD be removed. 


Future delivery is a message submission (e.g., [Submission]), not 
message relay feature. 


Delivery report request 

Requests for delivery status notifications (DSNs) SHOULD be 
transmitted in the [SMTP] envelope by using the DSN extension as 
specified in [DSN-SMTP] to request "success" or "none" notification 
(depending on the value of the ’X-Mms-—Delivery-Report’ header). When 
the NOTIFY extension is used, the unaltered recipient address SHOULD 
be transmitted as the ORCPT value. 

The ’X-Mms-Delivery-Report:’ header, if present, SHOULD be removed. 
Importance 

The message sender’s importance value (also called "priority", 
although this can be confused with class-of-service values) SHOULD be 


transmitted using an ’Importance:’ header. 


Suggested mappings are shown in Table 2: 
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2.1.3.2.1. Table 2: Importance Mappings (MMS to Internet Message) 


Normal importance messages should omit the ’Importance:’ header. 
The ’X-Mms-Priority:’ header, if present, SHOULD be removed. 
Sender visibility 

Support for sender address hiding is not currently supported. 


A message that contains an ’X-Mms-Sender-Visibility:’ header with a 
value of ’Hide’ SHOULD be rejected. 


The ’X-Mms-Sender-Visibility:’ header, if present, SHOULD be removed. 
Read reply request 


A request for a read reply SHOULD be transmitted using a 
'Disposition-Notification-To:’ header as specified in [MDN]. 


The ’X-Mms-Read-Reply:’ header, if present, SHOULD be removed. 
Reply charging 


Reply charging permission and acceptance are complex issues requiring 
both user agent and server support. Misapplied reply charging may 
cause incorrect billing. Until the security issues have been 
properly addressed, reply charging SHOULD NOT be honored when using 
this interface. 


The ’X-Mms-Reply-Charging:’, ’'X-Mms-Reply-Charging-Deadline:’, 'X- 
Mms-Reply-Charging-Size:’, and ’X-Mms-Reply-Charging-Id:’ headers MAY 
be removed. Messages containing a reply-charging usage request (’X- 
Mms-Reply-Charging-Id:’ and ’X-Mms-Reply-Charging: accepted’ or 'X- 
Mms-Reply-Charging: accepted (text only)’ headers) SHOULD be 
rejected. 
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Subject 


The ’Subject:’ header MUST be preserved. The current Internet 
message format requires that only 7-bit US-ASCII characters be 
present. Other characters MUST be encoded according to [Hdr-Enc]. 
Note that it is possible for an [SMTP] extension to be defined that 
would permit transmission of unencoded 8-bit characters, but in the 
absence of such an extension, [Hdr-Enc] MUST be used. 


Resending 

A message may be resent to one or more new recipients. It may be 
resent more than once, each time new ’Resent-—’ headers are added at 
the top of the existing headers. Thus, if more than one series of 


'Resent-’' headers are present, the original series is the last; the 
most recent is the first. 


Forward counter 


An 'X-Mms-Forward-Counter:’ header, if present, SHOULD be removed. 
The ’Resent-Count:’ header is NOT RECOMMENDED. Loop control is 
usually done by counting ’Received’ headers, which are more general 
than ’Resent-’ headers. 


Previously-Sent Information 


MMS lists the resending history of a message in two headers: '’X- 
Mms-Previously-Sent-By:’ and ’X-Mms-Previously-Sent-—Date-and-Time:’. 
’X-Mms-Previously-Sent-By:’ contains a number followed by one or 
more addresses. ‘’X-Mms—Previously-Sent—Date-and-Time:’ contains a 
number followed by a date-time. With both headers, the number "0" is 
used for the entry that corresponds to the original submission of the 
message, with higher values being used for each subsequent resending. 
The final (most recent) resending information is in the ’From:’ and 
‘Date:’ headers. There is also an ’X-Mms-Forward-Counter:’ that 
indicates how many times the message has been resent. 


Any ’X-Mms-Previously-Sent-By:’, ‘’X-Mms-—Previously-Sent-—Date-and- 
Time:’, and ’X-Mms-Forward-Counter:’ headers, if present, SHOULD be 
removed. The information contained in them SHOULD be translated into 
[Msg-Fmt] headers as follows: 


The ’X-Mms-Previously-Sent—Date-and-Time:’ header whose value starts 
with "0" SHOULD be used to create a ’Date:’ header, converting the 
date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The ’X- 
Mms-—Previously-Sent-By:’ header whose value starts with "0" SHOULD be 
used to create a ’From:’ header. 
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A 'To:’ header SHOULD be created using list syntax with a value of 
"unrecoverable-recipients" and no mailboxes. 


A ‘'Message-ID:’ header SHOULD be created. 


Any '’X-Mms-Previously-Sent-—Date-and-Time:’ headers whose value starts 
with "1" or a larger value are mapped to ’Resent-Date:’ headers. 

Any '’X-Mms-Previously-Sent-By:’ headers whose value starts with "1" 
or a larger value are mapped to ’Resent-By:’ headers. 


The ’From:’, ‘'To:’, ‘’Date:’, and ’Message-ID:’ headers are mapped to 
"Resent-From:’, ’Resent-To:’, ‘’Resent-Date:’, and ’Resent-—Message- 
ID:’ headers in the top-most block of ’Resent-*’ headers. 

Example: 


The MMS message: 


X-Mms-Forward-Counter: 2 
X-Mms—Previously-Sent-—Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT 


X-Mms-—Previously-Sent-By: 0, General Failure <mfail@example.mil> 
X-Mms—Previously-Sent-—Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT 
X-Mms-—Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil> 

Date: Fri, 1 Apr 2005 18:02:03 -0800 

From: L. Eva Message <lem@example.org> 

To: biff@mms.example.com 

Message-ID: <99887766.112233@mail.example.org> 


is mapped to an Internet mail message: 


Resent-—Date: Fri, 1 Apr 2005 18:02:03 -0800 
Resent-From: L. Eva Message <lem@example.org> 
Resent-To: biff@mms.example.com 

Resent-—Message-ID: <99887766.112233@mail.example.org> 
Resent-—Date: Fri, 1 Apr 2005 08:02:03 +0000 
Resent-From: Colonel Corn <gcorn@example.mil> 


Date: Fri, 1 Apr 2005 06:02:03 +0000 
From: General Failure <mfail@example.mil> 
To: Colonel Corn <gcorn@example.mil> 


Message-ID: <000.000.000@gateway.example.org> 
‘Received:’ Headers 
When a message is gatewayed from MMS to Internet mail, a ’Received:’ 


header MUST be added as per [SMTP]. The "with" clause should specify 
"MMS". 
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A message MAY be rejected if the number of ’Received:’ headers 
exceeds a locally-defined maximum, which MUST conform to [SMTP] 
Section 6.2 and SHOULD be no less than 100. 


Privacy 


Note that MMS systems do not currently support the ’Privacy’ header 
field as described by [VPIM]. 


Content 
The message content appears in the message body. Note that Internet 


message format requires that line endings be encoded as US-ASCII CR 
LF octets; thus, charset encodings that do not have this property 


cannot be used in text/* body parts. (They may be used in other body 
parts, but only when they are suitably encoded or when binary 
transmission has been negotiated, e.g., [BINARY].) In particular, 


MMS allows UTF-16, whereas the Internet message format does not. 
UTF-16 encoding MUST be translated to UTF-8 or another charset and 
encoding that is suitable for use in Internet message 
format/protocols. 

2.1.3.3. Conversion of Messages from Internet to MMS Format 
3GPP MMS Version 
An ’X-Mms-3GPP-MMS-Version:’ header SHOULD be added. 


Message Type (of PDU) 


An ’X-Mms-Message-Type:’ header SHOULD be used in accordance with the 
specific MMS interface (e.g., MM1, MM4). 


Transaction ID 


An ’X-Mms-Transaction-Id:’ header SHOULD be used in accordance with 
the specific MMS interface (e.g., MM1, MM4). 


Message ID 


The ’Message-Id:’ header MUST be retained. If not present, it MUST 
be created, with a unique value. 


Recipient(s) address 


"To:’ and ’Cc:’ headers MUST be retained. 
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Each recipient contained in the [SMTP] envelope (RCPT TO values) MUST 
be considered a recipient of the message. Recipients who appear in 
address headers but not the [SMTP] envelope MUST be ignored. 
Recipients who appear in the [SMTP] envelope but do not appear in 
headers are considered "blind" (Bcc) recipients; such recipients MUST 
NOT be added to message headers (including address and trace headers) 
unless there is only one recipient total. 


Sender address 
The ’From:’ header MUST be retained. 
Content type 


The complete ’Content-Type:’ header (including any parameters) SHOULD 
be preserved. 


Message class 


An ’X-Mms-Message-Class: personal’ header MAY be created for all 
received messages with a non-null return path (MAIL FROM value in the 
SMTP envelope). An ’X-Mms-Message-Class: auto’ header MAY be created 
for messages with a null return path. 


Time of Expiry 


An ’X-Mms-Expiry:’ header SHOULD be created if the message contains a 
relative time to expiration in the DELIVER-BY extension with a by- 
mode of "R", as specified in [Deliver-By]. 


If the by-mode is "N", a "relayed" DSN MUST be issued per 
[Deliver-By] and an ’X-Mms-Expiry:’ header SHOULD NOT be created. 


Delivery report request 


An '’X-Mms-—Delivery-Report:’ header SHOULD be created for messages 
that request ’success’ or ‘none’ delivery status notification by use 
of the DSN extension as specified in [DSN-SMTP]. Requests for 
‘delay’ notifications or non-default actions, such as that only the 
message headers should be returned, cannot be mapped onto MMS headers 
and thus SHOULD be ignored. 
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Importance 


The message sender’s importance value (also called "priority", 
although this can be confused with class-of-service values) is 
expressed with an ’Importance:’ header. Historically, some clients 
used the older and non-standard ’X-Priority:’ header for this 
purpose. As a result, some clients generate both. 


An 'X-Priority:’ or ’Importance:’ header, if present, SHOULD be 


replaced with an ’X-Mms-Priority:’ header. If both headers are 
present, ’Importance:’ SHOULD be used. Suggested mappings are shown 
in Table 3: 


2.1.3.3.1. Table 3: Priority Mappings (Internet Message to MMS) 


Normal importance messages SHOULD omit the ’X-Mms-Priority:’ header. 
Sender visibility 

Support for sender address hiding is not currently supported. 

Read reply request 

A request for a read reply contained in a ’Disposition-Notification-— 
To:’ header as specified in [MDN] SHOULD be replaced with an ’X-Mms-— 
Read-Reply:’ header. 


Subject 


The ’Subject:’ header MUST be preserved. 
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Resending 


Mapping from ’Resent-—’ and other [Msg-Fmt] headers to ’X-Mms-— 
Previously-Sent-—’ headers SHOULD be done as follows: 


The original ’From:’ header is mapped to an ’X-Mms—Previously-Sent-— 
By:’ header with a leading "0" value. The value of the top-most 
‘Resent-From:’ header is mapped to the ’From:’ header. The value of 
each subsequent ’Resent-From:’ header is mapped to an ’X-Mms- 
Previously-Sent-By:’ header with the next larger leading value. 


The original ’Date:’ header is mapped to an ’X-Mms-—Previously-Sent-— 
Date-and-Time:’ header with a leading "0" value. Note that the value 
is also converted from date-time syntax [Msg-Fmt] to HTTP-date syntax 
[HTTP]. The value of the top-most ’Resent-—Date:’ header is mapped to 
the ’Date:’ header. The value of each subsequent ’/Date:’ header is 
mapped to an ’X-Mms-—Previously-—Sent-—Date-and-Time:’ header with the 
next larger leading value. 


If one or more ’Resent-Message-ID:’ headers are present, the top-most 
one SHOULD be mapped to ’/Message-ID:’; otherwise, the ’Message-ID:’ 
header should be retained. 


An 'X-Mms-Forward-Counter:’ header SHOULD be created when ’Resent-’ 
headers have been mapped to ’X-Mms-Previously-Sent-—’ headers. Its 
value SHOULD be the number of ’Resent-—’ blocks that existed prior to 


mapping. 


Example: 


The original message: 


Date: Fri, 1 Apr 2005 14:02:03 -0800 
From: General Failure <mfail@example.mil> 
LO: Colonel Corn <gcorn@example.mil> 
Message-ID: <msg123@mail.example.mil> 


Is resent by Colonel Corn to L. Eva Message: 


Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800 
Resent-From: Colonel Corn <gcorn@example.mil> 


Resent-To: L. Eva Message <lem@example.org> 
Resent-—Message-ID: <msg234@mail.example.mil> 
Date: Fri, 1 Apr 2005 14:02:03 -0800 
From: General Failure <mfail@example.mil> 
TOs Colonel Corn <gcorn@example.mil> 
Message-ID: <msg123@mail.example.mil> 
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L. Eva then resends to her MMS device: 


Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800 
Resent-From: L. Eva Message <lem@example.org> 
Resent-To: biff@mms.example.com 

Resent-—Message-ID: <99887766.112233@mail.example.org> 
Resent-—Date: Fri, 1 Apr 2005 16:02:03 -0800 
Resent-From: Colonel Corn <gcorn@example.mil> 


Resent-To: L. Eva Message <lem@example.org> 
Resent-—Message-ID: <msg234@mail.example.mil> 
Date: Fri, 1 Apr 2005 14:02:03 -0800 
From: General Failure <mfail@example.mil> 
To: Colonel Corn <gcorn@example.mil> 
Message-ID: <msg123@mail.example.mil> 


This would be mapped to an MMS message as: 


X-Mms-Forward-Counter: 2 


X-Mms—Previously-Sent-—Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT 
X-Mms-—Previously-Sent-By: 0, General Failure <mfail@example.mil> 
X-Mms—Previously-Sent-—Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT 
X-Mms-—Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil> 

Date: Fri, 1 Apr 2005 18:02:03 -0800 

From: L. Eva Message <lem@example.org> 

To: biff@mms.example.com 

Message-ID: <99887766.112233@mail.example.org> 


Note that the original ’From:’ and ’Date:’ values were moved to ’X- 
Mms-Previously-Sent-By:’ and ’X-Mms—Previously-Sent-—Date-and-Time:’ 


headers with a leading "0" value. The first ’Resent-From:’ and 
"Resent—Date:’ values were moved to a second set of ’X-Mms- 
Previously-Sent-—’ headers, with a leading "1" value. The third set 


of ’Resent-’ headers were moved to the ’Date:’, '’To:’, and ’From:’ 
headers. 


Note also that the format of the date and time differs between the 
'Date:’ / 'Resent-Date:’ and the ’X-Mms-Previously-Sent-—Date-and- 

Time:’ headers, in that the latter use HTTP-date [HTTP] instead of 
date-time [Msg-Fmt]. 


"Received:’ Headers 


Each system that processes a message SHOULD add a ’Received:’ header 
as per [SMTP]. A message MAY be rejected if the number of 
"Received:’ headers exceeds a locally-defined maximum, which MUST 
conform to [SMTP] Section 6.2 and SHOULD be no less than 100. 
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Sensitivity 


The ’Sensitivity:’ header field (value = "personal" or "private") 
[VPIM] indicates the desire of a voice message originator to send the 
message contents to the original recipient list with assurance that 
the message will not be forwarded further by either the messaging 
system or the actual message recipient(s). Since sensitivity is not 
an MMS feature, any messages that contain a ’Sensitivity:’ header 
MUST NOT be sent to an MMS system. The associated negative delivery 
status report MUST include the extended status code [RESP] 5.6.0 as 
specified in [VPIM] ("Other or undefined protocol status") indicating 
that privacy could not be ensured. 


Content 


The message content appears in the message body. 
2.1.4. Report Generation and Conversion 


Internet message systems use the multipart/report MIME type for 
delivery and disposition reports as specified in [Report-Fmt]. This 
format is a two- or three-part MIME message; one part is a structured 
format describing the event being reported in an easy-to-parse 


format. Specific reports have a format that is built on 
[Report-Fmt]. Delivery reports are specified in [DSN-Msg]. Message 
disposition reports, which include read reports, are specified in 
[MDN]. 


By contrast, MMS reports are plain text, with no defined structure 
specified. This makes it difficult to convert from an MMS report to 
a standard Internet report. 


An implementation conforming to this specification MUST convert 
reports received from one side (MMS or Internet mail) destined for 
the other. In addition, reports MUST be generated as appropriate for 
messages received from either side. For example, if an MM to be sent 
via Internet mail is not deliverable, a delivery status MM shall be 
generated. Likewise, if an Internet message is received that cannot 
be further relayed or delivered, a delivery status report [DSN-Msg] 
MUST be generated. 


When creating delivery or disposition reports from MMS reports, the 
MMS report should be parsed to determine the reported event and time, 


status, and the headers of the referenced (original) message. These 
elements, once determined, are used to populate the subparts of the 
delivery or disposition report. The first subpart is of type 


text/plain, and contains a human-readable explanation of the event. 
This text may include a statement that the report was synthesized 
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based on an MMS report. The second subpart is of type 
report/delivery-status (for delivery reports) or report/disposition- 
notification (for disposition reports). This second part contains a 
structured itemization of the event. The optional third subpart is 
of type message/rfc822 and includes the headers and optionally the 
body of the referenced (original) message. Note that, per [DSN-Msg], 
the ’DSN-Gateway:’ field in delivery reports MUST be created. 


Delivery Report Mapping from MMS to Internet Message 


Below, Table 4 maps information elements from MMS delivery reports to 
the format specified in [DSN-Msg]. 
Table 4: 


Delivery Report Mappings (MMS to Internet Message) 


ieee Delivery 
|Report Elem 


Information Element 


[DSN-Msg] Element 


ID of message whose |Message-Id: 
delivery status is 


being reported 


Recipient address of 
the original message 
(object of delivery 
report) 


rj 
B 
fe) 
3 


Destination address of]|To: 


report 


| 
| 
Date and time the | 
| 
| 


message was handled 


Gellens 


Standards Track 


' Message-ID: preserved in third 


subpart of delivery report. 


'Final-Recipient’ field of the 
per-recipient section. 


'To:’ header field value of top- 

| level 

|’Date:’ header field value of top- 
| level 
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Information Element | MMS Delivery | [DSN-Msg] Element 
Report Elem 


X-Mms- |Action and Status fields of 
Status: |per-recipient section. 


Delivery status of 
original message to 
each recipient 

|The ‘Action’ field indicates if the 
message was delivered. 


|For failed delivery, an appropriate 
|’Status’ value shall be included 
|per [DSN-Msg] . 


|The Action field is set to one of 
foe following values: 


| 

| 

| 

| 

| 

| 

| 

| |* delivered (used for MMS status 

| |values ‘retrieved’ and 'rejected’, 
| | depending on ’Status’ code). 

| | 

* failed (used for MMS status 
values ’expired’ and ‘unreachable’ ) 
| 

| 

| 

| 

| 

| 

| 


|* delayed MAY be used for MMS 
|status value ‘deferred’ 


* relayed (used for MMS status 
value ’indeterminate’ ) 


|* expanded (SHOULD NOT be used) 


|Text in first part (human-readable 
part). 


When an MMS Relay/Server generates a [DSN-Msg] in response to a 
message received using [SMTP] on MM3: 


* Top-level header field ’To:’ SHOULD be the [SMTP] return-path of 
the message whose status is being reported. 


* Top-level header field ’From:’ SHOULD be the address of the 
recipient that the delivery-report concerns. 


* The first part of the [DSN-Msg] SHOULD include the MM Status Text 
field that would have been generated for an MM1 delivery-report. 
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2.1.4.2 Delivery Report Mapping from Internet Message to MMS 


Below, Table 5 maps information elements from a delivery report as 
specified in [DSN-Msg] to the format of an MMS delivery report. Note 
that a single DSN that reports multiple recipients will result in 


several MMS delivery reports. 


2 le AN Zala Table 35:3 


Delivery Report Mappings (Internet Message to MMS) 


Information Element | MMS Delivery 
|Report Element 


[DSN-Msg] Element 


ID of the original |Message-Id: 
message (object of 
delivery report) 
Recipient address 
of the original 
message (object of 
delivery report) 


Destination address 
of report 


Date and time the 
message was handled 


Gellens 


Standards Track 


'Message-ID:’ header preserved 
in third sub-part of report. 


| If available, the ’Original 
|-Recipient’ field of the per- 
|recipient section should be 
|used; otherwise, the ’Final- 
Recipient’ field of the per- 
recipient section is used. 


|’To:’ header field value of 
|top-level. 

Value taken from [SMTP] envelope 
return-path of message being 
|reported, not its ’From:’ header 
|field. 

|’Date:’ header field value of 
top-level. 
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Information Element 


| MMS Delivery 
Report Element 


[DSN-Msg] Element 


Delivery status of 
original message 


Status Text 


|X-Mms-Status: 
|Set to one of the 
|following values: 


(used 
|for ‘Action’ value 
|’ delivered’). 

| 

| 

| 


‘retrieved’ 


(used for ’Action’ 


value ’ failed’ ) 


|’ forwarded’ (used 
|for ‘Action’ value 
|’ relayed’) 


' deferred’ MUST 
NOT be used 
(ignore DSNs with 
‘Action’ value 


’delayed’) 


| 
| 
| 
| 
| 
| 
| 
| 
‘unreachable’ | 
| 
| 
| 
| 
| 
| 
| 
| 


‘Action’ and ’Status’ fields of 


per-recipient section. 


Text in first part (human- 


readable part). 


2.15453. 


Below, 


format specified in [MDN]. 


2.1.4.3.1. Table 6 


: Read Report Mappings 


Read Report Mapping from MMS to Internet Message 


Table 6 maps information elements from MMS read reports to the 


(MMS to Internet Message) 


Information Element 


MMS Delivery 
Report Elem 


[MDN] Element 


ID of the original 
message (object of 
read report) 


Recipient address of 
the original message 


Gellens 


| 
|Message-Id: 
| 


Standards Track 


"Message-ID:’ 
third part of report. 


'Final-Recipient’ 


header preserved in 


field. 
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Information Element |MMS Delivery| [MDN] Element 
Report Elem 


Destination address of|To: |’To:’ header field value of top- 
report er 

|Value taken from ’Disposition- 
Notification-To:’ header field of 
message being reported, not its 
'From:’ header field. 


Date and time the 
message was handled 


X-Mms-Read- 
Status: 


Disposition of message Disposition-field 


being reported 


|For X-MMS-Read-Status value ‘read’, 
[use 'disposition-type’ value 
|’ displayed’; for X-MMS-Read-Status 
|value ’Deleted without being read’, 
use ’disposition-type’ value 
We actors 
|Text in first part (human-readable 
|part) . 


When an MMS Relay/Server generates an [MDN] in response to a message 
received using [SMTP] on MM3: 


Status Text 


* Top-level header field ’To:’ SHOULD be the value of the 
'Disposition-Notification-To:’ header field of the message whose 
disposition is being reported. 


* Top-level header field ’From:’ SHOULD be the address of the 
recipient that the read report concerns. 


2.1.4.4. Disposition Report Mapping from Internet Message to MMS 


Below, Table 7 maps information elements from a disposition report as 
specified in [MDN] to the format of an MMS read report. 


Gellens Standards Track [Page 25] 


RFC 4356 Mapping Between MMS and Internet Mail January 2006 


2.1.4.4.1. Table 7: Disposition Report Mappings 
(Internet Message to MMS) 


Information Element |MMS Read Report 


| 

| [MDN] Element 
|Element | 

| 

| 


ID of the original |Message-Id: 
message (object of 
disposition report) 


'Message-ID:’ header preserved 
in third subpart of report. 


rj 
B 
fe) 
3 


Recipient address |’Final-Recipient’ field. 

of the original | 

message | 

Destination address |To: 'To:’ header field value of 

of report top-level. 
| |Value taken from ’Disposition- 
| |Notification-To:’ header field 
| lof message being reported, not 
| its 'From:’ header field. 

Date and time the |Date: |’Date:’ header field value of 

message was handled| |top-level. 

Disposition of |X-Mms-Read-Status: |disposition-field. 

message being 

reported Set to one of the 


|following values: 
|’ read’ (used for 
| disposition-type 
value '/displayed’ ) 


| 

| 

| 

|’Deleted without | 

|being read’ (used | 

|for disposition- | 

[types ‘deleted’, | 
‘denied’ and 

‘failed’ when | 

|action-mode is | 

|’ automatic- | 

| 

| 


Text in first part (human- 
readable part). 


Status Text | 
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2.1.5. Message Delivery 


Within Internet mail, when [SMTP] is used and delivery reports are 
requested [DSN-SMTP], delivery is considered to be acceptance of a 
message by the final server, that is, the server closest to the 
recipient. When an MMS Relay/Server receives a message using [SMTP] 
and a delivery report is requested, the MMS Relay/Server MAY consider 
the message delivered when it has been sent to the MMS User Agent. 


3. Security Considerations 


Both MMS and Internet mail have their own set of security risks and 
considerations. This document specifies how to exchange messages 
between these two environments, so it is only appropriate to discuss 
considerations specific to this functionality, not those inherent in 
either environment. 


When a message uses end-to-end security mechanisms such as [PGP] or 
S/MIME [SMIME], servers MUST be careful not to accidently destroy the 
integrity of the protected content (for example, by altering any text 
within the region covered by a signature while mapping between MMS 
and email). [Mime-Sec-gw] discusses issues with use of such 
mechanisms in gateways. 


Some MMS features contain inherently more risk than others, including 
reply charging and sender address hiding. Support for these 
mechanisms is not included in this document. 


4. IANA Considerations 


IANA has added "MMS" as one of the "WITH protocol types" under its 
"MAIL Parameters" registry. The description is "Multimedia Messaging 
Service"; the reference is to this document. 
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